User interface modality switching for transaction management

ABSTRACT

A method may include presenting a user interface (UI), to a user, in a first mode on a client device, the UI including a list portion, the list portion including a plurality of transactions associated with respective activity on a user account, and the client device including an input device; receiving an indication of a first user action on a transaction presented in the list portion of the UI; in response to receiving the indication, updating a section of the list portion corresponding to the transaction, the updating including revealing a set of options for the transaction; receiving an indication of a second user action corresponding to activation of an option of the set of options; and in response to receiving the indication of the second user action, transitioning the UI from the first mode to a second mode, the second mode including a chatbot interface instantiated with respect to the transaction.

RELATED APPLICATIONS

This patent application is a continuation of U.S. patent applicationSer. No. 17/445,138, filed Aug. 16, 2021, now issued as U.S. Pat. No.11,609,773, which is a continuation of U.S. patent application Ser. No.16/354,958, filed Mar. 15, 2019, now issued as U.S. Pat. No. 11,093,265,which claims the benefit of priority, under 35 U.S.C. § 119(e), to U.S.Provisional Patent Application Ser. No. 62/643,381, titled “USERINTERFACE MODALITY SWITCHING FOR TRANSACTION MANAGEMENT,” filed on Mar.15, 2018, which is incorporated by reference in its entirety.

BACKGROUND

As mobile devices become increasingly powerful, they often are the mainor only computing devices for users. Using mobile devices creates anumber of technical challenges due to the limited screen size and inputmethods compared to a desktop computer.

In some instances, a user may interact with a chatbot on a mobiledevice. The chatbot may help the user place an order, reserve a spot ata restaurant, or retrieve the current weather forecast. Often thechatbot interface is self-contained and does not have knowledge of dataoutside of what has been inputted by the user.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, which are not necessarily drawn to scale, like numeralsmay describe similar components in different views. Like numerals havingdifferent letter suffixes may represent different instances of similarcomponents. Some embodiments are illustrated by way of example, and notlimitation, in the figures of the accompanying drawings.

FIG. 1 is a schematic drawing illustrating an application and atransaction server, according to various examples.

FIG. 2 is an account selection interface, according to various examples.

FIG. 3 is a transaction list interface, according to various examples.

FIG. 4 illustrates an interaction with a transaction, according tovarious examples.

FIGS. 5-12 are chatbot interfaces, according to various examples.

FIG. 13 illustrates a claim details interface, according to variousexamples.

FIG. 14 is a chatbot interface, according to various examples.

FIG. 15 is a claim form interface, according to various examples.

FIG. 16 is a flowchart diagram illustrating a method, according tovarious embodiments.

FIG. 17 is a block diagram illustrating an example machine upon whichany one or more of the techniques (e.g., methodologies) discussed hereinmay be performed, according to an example embodiment.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of some example embodiments. It will be evident, however,to one skilled in the art that the present invention may be practicedwithout these specific details.

Throughout this disclosure, electronic actions may be taken bycomponents in response to different variable values (e.g., thresholds,user preferences, etc.). As a matter of convenience, this disclosuredoes not always detail where the variables are stored or how they areretrieved. In such instances, it may be assumed that the variables arestored on a storage device accessible by the component via anApplication Programming Interface (API) or other program communicationmethod. Similarly, the variables may be assumed to have a default valuesshould a specific value not be described. Various systems may provide auser interface for an end-user or administrator to edit the variablevalues in some instances

Customer service still often requires a customer to call a phone numberof a company and speak to an actual representative. Although interactivevoice response (IVR) systems are prevalent, they suffer from a number ofproblems. For example, IVR systems are inherently auditory in nature.Thus, confirmations to a customer require repeating back information.Additionally, IVR systems require provisioning of physical resourcessuch as telephone lines in order to handle customer calls.

Customer chat is another channel of customer service that isincreasingly common. Yet, the deployment of a chat interface isgenerally put on a website of a business with no context as to what thecustomer is doing. Accordingly, even if a customer is looking at his orher bill and has a question, the customer may still need to enter in thecustomer's account number, etc., into the chat interface.

Systems and methods described herein are directed towards a new userinterface model to help alleviate the limitations of current userinteraction models on mobile devices, IVR systems, and chat interfaces.For example, a system may include a user interface on a mobile devicethat includes a first modality that includes a list of transactions anda second modality with a chatbot interface that is instantiated based onselection of a transaction of the list of transactions. In doing so, thelimited display size of a mobile device may be efficiently used for auser to interact with a business and physical resources of the businessmay not be needed (e.g., telephone lines and computing systems forCSRs).

FIG. 1 is a schematic drawing illustrating an application and atransaction server. FIG. 1 includes client device 102, transactionserver 104, and application 106. Application 106 includes chatbotinterface 108, input processing 110, authorization component 112, listinterface 114, and location determination component 116. Transactionserver 104 includes application programming interface (API) 118,transaction database 120, web server 122, and claim objects 124.

For illustration purposes, application 106 and transaction server 104are illustrated as set of separate components. However, thefunctionality of individual components may be performed by a singlecomponent. A component may represent computer program code that isexecutable by a processing unit (e.g., a core of a general-purposecomputer processor, a graphical processing unit, an application specificintegrated circuit, etc.) The program code may be stored on a storagedevice and loaded into a memory of the processing unit for execution.Portions of the program code may be executed in a parallel acrossmultiple processing units. Execution of the code may be performed on asingle device or distributed across multiple devices. In some example,the program code is executed on a cloud platform (e.g., MICROSOFT AZURE®and AMAZON EC2®) using shared computing infrastructure.

Similarly, the location of the components may be different in differentexamples. For example, application 106 may be a wrapper around aweb-client that is accessing a webpage hosted by web server 122.Accordingly, some or all of input processing related to userinteractions with data may occur at transaction server 104. Similarly,the logic/rules for presentation of chatbot interface 108 and listinterface 114 may also reside in transaction server 104 in someexamples.

In various examples, the assets and components in FIG. 1 may communicatevia one or more networks (not illustrated). A network may includelocal-area networks (LAN), wide-area networks (WAN), wireless networks(e.g., 802.11 or cellular network), the Public Switched TelephoneNetwork (PSTN) network, ad hoc networks, cellular, personal areanetworks or peer-to-peer (e.g., Bluetooth®, Wi-Fi Direct), or othercombinations or permutations of network protocols and network types. Anetwork may include a single local area network (LAN) or wide-areanetwork (WAN), or combinations of LAN's or WAN's, such as the Internet.

Client device 102 may be, but is not limited to, a smartphone, tablet,laptop, multi-processor system, microprocessor-based or programmableconsumer electronics, game console, set-top box, or any other devicethat a user utilizes to communicate over a network. In exampleembodiments, client device 102 comprises a display module (not shown) todisplay information (e.g., in the form of specially configured userinterfaces). In some embodiments, client device 102 may comprise one ormore of a touch screen, camera, keyboard, microphone, and GlobalPositioning System (GPS) device.

In some examples, client device 102 may lack physical input mechanismsbeyond a touchscreen. Accordingly, the primary interfaces for user maybe gesture-based touch controls or audio input. As discussed furtherherein, input processing 110 may execute program code based on inputsreceived by application 106.

Application 106 may be downloaded through an app store provided by amanufacturer of client device 102 and installed on client device 102. Inother examples, application 106 may be downloaded directly from thecreator of application 106 via a website. Application 106 may providedata concerning user activity associated with a user account. Forexample, application 106 may be associated with a financial institutionand the user activity may be debits or credits related to transactionaccounts for the user.

Authorization component 112 may be used to authorize the user withrespect to application 106 as well as transaction server 104. Forexample, application 106 may present a user interface in which the usermay enter in a username and password. Other authentication techniquesmay be used without departing from the scope of this disclosureincluding, but not limited to, facial identification and fingerprintscanning. While communicating with transaction server 104, an indicationof the authorization status of user may be transmitted as well. Thus, iftransaction data is being requested from transaction server 104, aseparate authentication request may not be needed.

The user interface (UI) of application 106 may operate in a number ofmodes (modalities) for interacting with the past user activity. Forexample, list interface 114 may be used to present a list of transactionaccounts of a user and activity of the accounts (e.g., transactions) inchronological or other orders (e.g., amount, type, etc.). When usinglist interface 114, the user may interact using touch or other physicalinput mechanisms (e.g., mouse, styluses), etc. List interface 114 may beuseful for a user to see an overview of all the user's transactions. Indoing so, the user may notice that one of transactions was unauthorized.Unauthorized may mean a transaction was made by someone other than theuser. For example, the card number for a checking account of the usermay have been taken and used fraudulently to purchase an item.

Traditionally, when a user notices unauthorized activity, the user isforced to make a telephone call to the provider of the account (e.g.,the user's bank). The user may have to authenticate themselves to acustomer service representative (CSR) despite the user having alreadyauthenticated themselves within an application (e.g., usingauthorization component 112) or a website.

Additionally, the user may have to repeat information related to theunauthorized transaction to the CSR. Furthermore, the CSR may have tomanually repeat a number of transactions that may or may not have beenunauthorized to get confirmation of their authenticity from the user.Finally, in many cases, after a claim has been created that identifiesunauthorized transactions, users are unable to check on the status ofthe claim. Some systems may proactively notify a user of potentiallyfraudulent activity on the user's account. Yet, even then, the user isoften forced to make a telephone call and have a similar back-and-forthconversation as described above.

List interface 114 may be configured to alleviate the need for atelephone conversation with CSR. For example, a user may select one ormore transactions believe to be unauthorized. Input processing 110 mayprocess the selection to obtain transaction details on thetransaction(s) identified by the selection. For example, a transactionidentifier, amount, and date of the transaction may be determined.

Upon receiving the transaction details, the user interface ofapplication 106 may transition to chatbot interface 108. Transitioningmay include passing (e.g., using an API) transaction details on theidentified transactions to chatbot interface 108. Using these details, aseries of questions may be presented to the user via an automatedchatbot. The user may answer using voice or other input mechanisms suchas a keyboard or touch interface, which may be processed by inputprocessing 110 of a client device 102. Processing may include performingvoice-to-text analysis and natural language processing as are known tothose skilled in the art. A more detailed walk-through example of usinglist interface 114 chatbot interface 108 is discussed beginning withFIG. 2 .

Chatbot interface 108 may operate according to an underlying chatbotmodel (e.g., an automated electronic digital assistant). The model mayact according to a set of predefined business rules and/or trainedmachine leaning (ML) model. Business rules may a define a series ofif/then operations; whereas an ML model may offer more flexibility. Forexample, if a user's response does not conform to one of the predefinedbusiness rules, the chatbot may have to resort to asking the user to tryanother response. In contrast, an ML model, such as a neural network ork-means clustering, may make a guess based on probabilities of what theuser's intent was, regardless of whether the user's response has beenseen before. In either case, the chatbot may be trained or otherwiseimproved over time based on interactions with user(s) as one skilled inthe art would recognize.

Location determination component 116 may be used to determine thelocation of client device 102. In an example, location determinationcomponent 116 issues a query to operating system of client device 102for the location. The operating system may access sensor data (e.g.,from a GPS sensor) to determine the location. The location may be a setof geo-coordinates or geographic location (e.g., address). Application106 may use this information to direct the user to physicalestablishments that may be able to issue a replacement card or temporarycard for a user's account. The location may also be used by a financialinstitution as a factor in denying a transaction or as an authenticationfactor.

Transaction database 120 may store data on transactions for a number ofusers. A transaction may be stored according to a standardized datastructure. For example, the transaction data structure may includefields for transaction account identification (e.g., checking accountnumber), transaction type (e.g., debit/credit), authorization status(e.g., approved, pending, unauthorized), date, and amount. More or fewerfields may be used without departing from the scope of this disclosure.The account identification may correspond to a user account. A useraccount may be associated with multiple transaction accounts.

Claim objects 124 may be data structures that identify one or moretransactions as unauthorized. A claim object may be generated during auser's interaction with chatbot interface 108. The claim object may alsoinclude a status (e.g., open, complete, etc.), a claim identifier, auser identifier, a data created, transaction identifier(s), etc. Claimobjects 124 may be stored in transaction database 120 in some examples.

Data used by application 106 and transaction server 104 may be organizedand stored in a variety of manners. For convenience, the organizedcollection of data is described herein as transaction database 120. Thespecific storage layout and model used in transaction database 120 maytake a number of forms—indeed, transaction database 120 may utilizemultiple models. The database 116 may be, but is not limited to, arelational database (e.g., SQL), non-relational database (NoSQL) a flatfile database, object model, document details model, graph database,shared ledger (e.g., blockchain), or a file system hierarchy.Transaction database 120 may store data on one or more storage devices(e.g., a hard disk, random access memory (RAM), etc.). The storagedevices may be in standalone arrays, part of one or more servers, andmay be located in one or more geographic areas.

API 118 and web server 122 may be used together to present data onclient device 102 and send/receive data with application 106. An APIprovides a method for computing processes and systems to exchange data.A web-based API, such as API 118, may permit communications between twoor more computing devices. The API may define a set of HTTP callsaccording to Representational State Transfer (RESTful) practices.

A RESTful API may define various GET, PUT, POST, DELETE methods tocreate, replace, update, and delete data stored on a transactiondatabase 120. For example, application 106 may use a“GET/transactions/userid” call to retrieve transaction for theidentification indicated by “userid” and display them in list interface114. Another API call may be used to create a claim object thatidentifiers a series of transaction identifiers. API 118 may transmitresponses to requests for data according to the JavaScript ObjectNotation (JSON) format. Similarly, data transmitted via API 118—fromapplication 106, for example—may be encoded in the JSON format andsubmitted in the content portion of a PUT request.

Web server 122 may be used to exchange information with users via anetwork such as the Internet. Although generally discussed in thecontext of delivering webpages via the Hypertext Transfer Protocol(HTTP), other network protocols may be utilized by web servers 110(e.g., File Transfer Protocol, Telnet, Secure Shell, etc.) A user mayenter in a uniform resource identifier (URI) into a network browser(e.g., the INTERNET EXPLORER® web browser by Microsoft Corporation orSAFARI® web browser by Apple Inc.) that corresponds to the logicallocation (e.g., an Internet Protocol address) of a webpage hosted by webserver 122. In response, web server 122 may transmit a webpage/application that is rendered on a display device of client device102. In some examples, the web application is application 106.

FIG. 2 is an account selection interface, according to various examples.The account selection interface may be part, of or be presented, byapplication 106. FIG. 2 may be presented after a user authenticatesthemselves with application 106. For example, application 106 may usethe credentials entered by the user and transmit them to transactionserver 104. In response, server 104 may return identifiers oftransaction accounts associated with the user credentials. Asillustrated, the transaction accounts may include a savings account anda checking account 202. The user may make a selection on the accountselection interface—such as checking account 202—to see activityassociated with the selected account.

FIG. 3 is a transaction list interface, according to various examples.The transaction list interface may include a list portion 302 and useraction control 304 and be part of a UI of application 106. Thetransaction list interface may be presented in response to a selectionfrom an account selection interface. List portion 302 may include aplurality of transactions associated with respective user activity on auser account—in this case, a checking account. The plurality oftransactions may be received from transaction server 104.

Application 106 may receive indications of user actions with respect toparticular transactions resented in list portion 302. The indication maycome from, for example, the operating system (OS) of a client device.Consequently, if a user clicks with a mouse or touches a UI element withthe user's finger, the OS may transmit a signal to application 106 withthe location, and if applicable, a gesture identification (e.g., swipeleft) of the interaction. In response, application 106 may perform invarious functions as described further below.

FIG. 4 illustrates an interaction with a transaction, according tovarious examples. Individual transactions may be interacted with by auser using input device on the client device. For example, a user mayswipe left on a transaction. In response, a section of the list portioncorresponding to a transaction may be updated to reveal a set of options402 for the transaction. To make room for the options, a portion of thetransaction may be slid out of view in an animated fashion. Otherpresentation modes and techniques presenting the set of options 402 maybe used without departing from the scope of this disclosure. The set ofoptions 402 may include an option to file a claim using a claim forminterface—such as presented in FIG. 15 —and an option to use a chatbotinterface.

FIGS. 5-12 and 14 are chatbot interfaces, according to various examples.These figures are discussed in the context of the user interacting witha chatbot in a single chatbot session in chronological order; however, auser may interact with the chatbot without going through each of theillustrated interactions.

The chatbot session may begin in response to receiving an indication ofa user action corresponding to activation of an option (e.g., clicks amessage icon) of the set of options illustrated in FIG. 4 . For example,application 106 may transition its user interface from a first mode,which displays the list portion, to a second mode that includes achatbot interface. The chatbot interface may be instantiated withrespect to a particular selected transaction. Accordingly, thetransaction details of one or more user selected (e.g., clicks, swipes)transaction from the list may be saved for use in queries by the chatbotinterface. A transaction summary 508 may present the transaction detailsincluding an item name, purchase date, an amount, and how thetransaction was paid for.

The chatbot interface may be presented without the user selecting one ofthe options. For example, a financial institution may determine that atransaction was potentially fraudulent and transmit a push notificationto the client device 102 (e.g., via transaction server 104). The usermay click the push notification and the chat interface may beinstantiated with respect to the potentially fraudulent transaction.

With respect to FIG. 5 , it may be seen that a query with respect to astatus of a transaction is presented. The chatbot interface presentsoptions 504 and 506 with respect to the status. Voice response option502 may be used if a user would like to respond by voice instead of textinput or clicking/touching the options. If a user activates voiceresponse option 502, audio data may be received that has been capturedby the client device and processed to determine a response to the query.Processing may include converting the audio to text using techniquesknown in the art. The text may be compared to the presented options todetermine response by the user.

The audio response need not correspond directly to one of the presentedoptions. For example, instead of “I don't” the user may have responded“I do not recognize that transaction.” In such an instance, inputprocessing 110 may determine the likelihood that the user selected eachof the two presented options and select the more likely of the two. Anysuitable text similarity algorithm may be used, as are known in the art,without departing from the scope of this disclosure.

In the presented scenario, selection of option 504 may indicate thetransaction was authorized. In contrast, a selection of option 506 mayindicate that the user activity with respect to the displayedtransaction was not authorized by the user (e.g., was fraudulent).

Continuing to FIG. 6 , the chatbot interface has been updated to removethe options with respect to the query on the status of the transaction.In place of the options, a response received by and the user ispresented. Additionally, the chatbot interface indicates that the userhas responded affirmatively to generate a claim based on a transaction.

FIG. 7 continues a line of questioning to the user with respect to othertransactions that may not have been authorized by the user. For example,transaction 702 may have been a transaction that was made within athreshold amount of time of the transaction initially selected in thelist portion of the interface. The chatbot interface may present eachtransaction that is within the threshold and ask the user whether or notthe respective transaction was authorized/recognized. After thetransactions have been presented to the user, the user is given anoption to add comments to the claim in FIG. 8 .

After adding any comments, a claim object may be generated thatidentifies the transaction(s) as unauthorized. With respect to FIG. 9 ,a representation of the claim object 902 may be presented in the chatbotinterface. The representation of the claim object 902 may be a summaryof details of the claim object. Within a transaction details section904, a set of transactions identified by the user as unauthorized may bepresented. As illustrated, the three dots at the bottom of detailssection 904 may indicate that there are three transactions associatedwith the claim object. The first dot is filled in indicating that thetransaction details presented are for the first transaction in the setof transactions. Other visual/textual representations of the amount oftransactions may be used as well.

FIG. 10 illustrates transaction details section 904 with the middle dotfilled in—indicating the second transaction of the set of transaction isbeing displayed. The second transaction may be displayed in response toreceiving an indication of swipe user action on the claim object 902(e.g., within transaction detail section 904). Accordingly, therepresentation of the claim object may be updated. Some examples ofdating may include and animation of one transaction sliding off thescreen while presenting another transaction.

Upon a user confirming—such as selecting/saying “Submit now” in FIG. 10—a summary of actions taken by application 106 or transaction server 104may be presented to the user in FIG. 11 . Additionally, user interface(UI) map object may be presented in the chatbot interface identifying astore closest to the location of the client device operating application106. To determine the store closest to the location, a location of theclient device may be obtained and used as a query of a database ofstores using location. The database may be stored on client device 102or transaction server 104. The store may be a place in which a user maypick up a temporary card (e.g., a banking branch).

The chatbot interface may also be used by the user to complete tasksother than submitting a claim. For example, FIG. 12 presents claimobjects 1202 and 1204 in response to requests from the user via the chatinterface for a status update for a set of claims. Each of the claimsmay be associated with a respective set of transactions identified bythe user as unauthorized. The claim objects may be presented in a userinterface carousel claim object, wherein the user interface carouselclaim object is configured to accept input from the user to scrollthrough the set of claims. For example, a user may swipe left on claimobject 1202 to show more details of claim object 1204—while details ofthe same object 1202 may disappear off the left side of the screen. Eachof claim objects 1202 and 1204 also includes a status (e.g., “InProgress”) of the claim.

FIG. 13 illustrates a claim details interface, according to variousexamples. FIG. 13 may be presented in response to application 106receiving an indication that the user activated “view details” on claimobject 1202. The claim details interface may include a representation ofa claim object including the set of transactions identified by the userfor the selected claim. An option is also presented to withdraw theclaim. If the user activates the withdraw option, a query may bepresented requesting details as to why the user wants to withdraw theclaim.

FIG. 14 presents additional information that may be accessed using achatbot interface. For example, a link (1402) to initiate telephoniccommunication with the banker may be presented within the chatbotinterface. Upon clicking the number presented, the client device mayautomatically initiate a telephone call with the banker or CSR, forexample.

FIG. 16 is a flowchart illustrating a method, according to variousexamples. The method may be embodied in a set of instructions stored inat least one non-transitory storage device of a computing device(s). Thecomputing device(s) may have one or more processors that execute the setof instructions to configure the one or more processors to perform theoperations illustrated in FIG. 16 . To this end, the one or moreprocessors may instruct other parts of the computing device to carry outthe set of instructions. For example, the computing device may instructa network device to transmit data to another computing device or thecomputing device may provide data over a display interface to present auser interface. In some examples, performance of the method may be splitacross multiple computing devices.

At operation 1602, in various examples, a user interface (UI) may bepresented to a user, in a first mode on a client device. The UI mayinclude a list portion including a plurality of transactions associatedwith respective activity on a user account. The client device mayinclude an input device. The UI may be part of an application (e.g.,native or web) executing on the client device

At operation 1604, in various examples, an indication of a first useraction may be received on a transaction presented in the list portion ofthe UI. The indication may be received by the application. In responseto receiving the indication, a section of the list portion correspondingto the transaction may be updated (operation 1606). The updating mayinclude revealing a set of options for the transaction. Revealing theset of options for the particular transaction may include sliding aportion of the particular transaction out of view on the client device

At operation 1608, in various examples, an indication of a second useraction corresponding to activation of an option of the set of options isreceived. In response to receiving the indication of the second useraction, the UI may be transitioned from the first mode to a second mode(operation 1610). The second mode may include a chatbot interfaceinstantiated with respect to the transaction.

The method may include an additional operation of presenting a query inthe chatbot interface with respect to a status of the particulartransaction. For example, the query may request the user to indicatewhether or not a transaction was authorized.

Responses to queries in the chatbot interface may be made using amicrophone on the client device. The method may include processing audiodata (e.g., speech-to-text processing) received via the microphone todetermine a response to the query. In other examples, a user may type intheir responses in the chatbot interface.

The method may further include operations of receiving, via the chatbotinterface, a response from the user indicating that the user activitywith respect to the particular transaction was not authorized by theuser. Based on the response from the user, a claim object may begenerated that identifies the particular transaction as unauthorized. Arepresentation of the claim object (e.g., a graphic) may be presented inthe chatbot interface. The representation may include a set oftransactions identified by the user as unauthorized. Presenting mayinclude transmitting data from a server (e.g., transaction server 104)for display on the client device.

The method may further include operations of receiving an indication ofa swipe user interaction on the representation of the claim object.Based on the interaction, the representation of the claim object may beupdated to present details of another transaction identified by the useras unauthorized.

The method may further include operations of after receiving theresponse to the query in the chatbot interface, obtaining a location ofthe client device. Then, a database of stores may be queried using thelocation, Based on the responses to the query, a UI map object may bepresented in the chatbot interface that identifies a store closest tothe location of the client device.

The method may further include operations of receiving a request fromthe user via the chatbot interface for assistance with preventingunauthorized purchases. In response to receiving the request, aknowledge data store may be queries. Then, within the chatbot interface,information obtained in response to the querying may be presented.

The method may further include receiving a request from the user via thechatbot interface for a status update of a set of claims. The claim maybe associated with a respective set of transactions identified by theuser as unauthorized. In response the request, a UI carousel claimobject may be presented in the chatbot interface. The UI carousel claimobject may be configured to accept input from a user to scroll throughthe set of claims.

Furthermore, the method may include receiving an indication of aselection of a claim presented in the UT carousel claim object. Inresponse to receiving the selection, a representation of a claim objectmay be presented in the chatbot interface. The representation mayinclude a set of transactions identified by the user for the selectedclaim as unauthorized.

In various examples, the method may further include presenting, in thechatbot interface, a link to initiate a telephonic communication.

Example Computer System

Embodiments described herein may be implemented in one or a combinationof hardware, firmware, and software. Embodiments may also be implementedas instructions stored on a machine-readable storage device, which maybe read and executed by at least one processor to perform the operationsdescribed herein. A machine-readable storage device may include anynon-transitory mechanism for storing information in a form readable by amachine (e.g., a computer). For example, a machine-readable storagedevice may include read-only memory (ROM), random-access memory (RAM),magnetic disk storage media, optical storage media, flash-memorydevices, and other storage devices and media.

Examples, as described herein, may include, or may operate on, logic ora number of components, modules, or mechanisms. Modules may be hardware,software, or firmware communicatively coupled to one or more processorsin order to carry out the operations described herein. Modules mayhardware modules, and as such modules may be considered tangibleentities capable of performing specified operations and may beconfigured or arranged in a certain manner. In an example, circuits maybe arranged (e.g., internally or with respect to external entities suchas other circuits) in a specified manner as a module. In an example, thewhole or part of one or more computer systems (e.g., a standalone,client or server computer system) or one or more hardware processors maybe configured by firmware or software (e.g., instructions, anapplication portion, or an application) as a module that operates toperform specified operations. In an example, the software may reside ona machine-readable medium. In an example, the software, when executed bythe underlying hardware of the module, causes the hardware to performthe specified operations. Accordingly, the term hardware module isunderstood to encompass a tangible entity, be that an entity that isphysically constructed, specifically configured (e.g., hardwired), ortemporarily (e.g., transitorily) configured (e.g., programmed) tooperate in a specified manner or to perform part or all of any operationdescribed herein. Considering examples in which modules are temporarilyconfigured, each of the modules need not be instantiated at any onemoment in time. For example, where the modules comprise ageneral-purpose hardware processor configured using software; thegeneral-purpose hardware processor may be configured as respectivedifferent modules at different times. Software may accordingly configurea hardware processor, for example, to constitute a particular module atone instance of time and to constitute a different module at a differentinstance of time. Modules may also be software or firmware modules,which operate to perform the methodologies described herein.

FIG. 17 is a block diagram illustrating a machine in the example form ofa computer system 1700, within which a set or sequence of instructionsmay be executed to cause the machine to perform any one of themethodologies discussed herein, according to an example embodiment. Inalternative embodiments, the machine operates as a standalone device ormay be connected (e.g., networked) to other machines. In a networkeddeployment, the machine may operate in the capacity of either a serveror a client machine in server-client network environments, or it may actas a peer machine in peer-to-peer (or distributed) network environments.The machine may be an onboard vehicle system, wearable device, personalcomputer (PC), a tablet PC, a hybrid tablet, a personal digitalassistant (PDA), a mobile telephone, or any machine capable of executinginstructions (sequential or otherwise) that specify actions to be takenby that machine. Further, while only a single machine is illustrated,the term “machine” shall also be taken to include any collection ofmachines that individually or jointly execute a set (or multiple sets)of instructions to perform any one or more of the methodologiesdiscussed herein. Similarly, the term “processor-based system” shall betaken to include any set of one or more machines that are controlled byor operated by a processor (e.g., a computer) to individually or jointlyexecute instructions to perform any one or more of the methodologiesdiscussed herein.

Example computer system 1700 includes at least one processor 1702 (e.g.,a central processing unit (CPU), a graphics processing unit (GPU) orboth, processor cores, compute nodes, etc.), a main memory 1704 and astatic memory 1706, which communicate with each other via a link 1708(e.g., bus). The computer system 1700 may further include a videodisplay unit 1710, an alphanumeric input device 1712 (e.g., a keyboard),and a user interface (UI) navigation device 1714 (e.g., a mouse). In oneembodiment, the video display unit 1710, input device 1712 and UInavigation device 1714 are incorporated into a touch screen display. Thecomputer system 1700 may additionally include a storage device 1716(e.g., a drive unit), a signal generation device 1718 (e.g., a speaker),a network interface device 1720, and one or more sensors (not shown),such as a global positioning system (GPS) sensor, compass,accelerometer, or other sensor.

The storage device 1716 includes a machine-readable medium 1722 on whichis stored one or more sets of data structures and instructions 1724(e.g., software) embodying or utilized by any one or more of themethodologies or functions described herein. The instructions 1724 mayalso reside, completely or at least partially, within the main memory1704, static memory 1706, and/or within the processor 1702 duringexecution thereof by the computer system 1700, with the main memory1704, static memory 1706, and the processor 1702 also constitutingmachine-readable media.

While the machine-readable medium 1722 is illustrated in an exampleembodiment to be a single medium, the term “machine-readable medium” mayinclude a single medium or multiple media (e.g., a centralized ordistributed database, and/or associated caches and servers) that storethe one or more instructions 1724. The term “machine-readable medium”shall also be taken to include any tangible medium that is capable ofstoring, encoding or carrying instructions for execution by the machineand that cause the machine to perform any one or more of themethodologies of the present disclosure or that is capable of storing,encoding or carrying data structures utilized by or associated with suchinstructions. The term “machine-readable medium” shall accordingly betaken to include, but not be limited to, solid-state memories, andoptical and magnetic media. Specific examples of machine-readable mediainclude non-volatile memory, including but not limited to, by way ofexample, semiconductor memory devices (e.g., electrically programmableread-only memory (EPROM), electrically erasable programmable read-onlymemory (EEPROM)) and flash memory devices; magnetic disks such asinternal hard disks and removable disks; magneto-optical disks; andCD-ROM and DVD-ROM disks.

The instructions 1724 may further be transmitted or received over acommunications network 1726 using a transmission medium via the networkinterface device 1720 utilizing any one of a number of well-knowntransfer protocols (e.g., HTTP). Examples of communication networksinclude a local area network (LAN), a wide area network (WAN), theInternet, mobile telephone networks, plain old telephone (POTS)networks, and wireless data networks (e.g., Wi-Fi, 3G, and 4G LTE/LTE-A,5G, or WiMAX networks). The term “transmission medium” shall be taken toinclude any intangible medium that is capable of storing, encoding, orcarrying instructions for execution by the machine, and includes digitalor analog communications signals or other intangible medium tofacilitate communication of such software.

The above detailed description includes references to the accompanyingdrawings, which form a part of the detailed description. The drawingsshow, by way of illustration, specific embodiments that may bepracticed. These embodiments are also referred to herein as “examples.”Such examples may include elements in addition to those shown ordescribed. However, also contemplated are examples that include theelements shown or described. Moreover, also contemplate are examplesusing any combination or permutation of those elements shown ordescribed (or one or more aspects thereof), either with respect to aparticular example (or one or more aspects thereof), or with respect toother examples (or one or more aspects thereof) shown or describedherein.

What is claimed is:
 1. A computer-implemented method comprising:presenting a chatbot user interface (UI), to a user, on a client device,the chatbot UI instantiated with respect to a particular transaction ofa. plurality of transactions associated with respective activity on auser account; receiving, via the chatbot UI, a response from the userindicating that the user activity with respect to the particulartransaction was not authorized by the user; based on the response fromthe user, generating a claim object that identifies the particulartransaction as unauthorized; presenting a graphical representation ofthe claim object in the chatbot UI, the representation includingtransaction details of the particular transaction identified by the useras unauthorized; receiving an indication of a swipe user interaction onthe graphical representation of the claim object; and in response to theindication, updating a first portion of the graphical representation ofthe claim object to present details of another transaction identified bythe user as unauthorized while keeping a second portion of the graphicalrepresentation of the claim object the same.
 2. The method of claim 1,further comprising: prior to the generating, presenting a query in thechatbot UI to user to identify the another transaction as unauthorized;and based on receiving an affirmative response from the user via thechatbot UI, adding the another transaction as part of the claim object.3. The method of claim 2, wherein receiving the affirmative responsefrom the user via the chatbot UI includes: presenting a plurality ofselectable buttons in the chatbot UI, a first selectable buttonindicating the another transaction is recognized and a second selectablebutton indicating the another transaction is not recognized; andreceiving an indication the second selectable button has been activated.4. The method of claim 2, further comprising: prior to the generating,presenting a query in the chatbot UI to user requesting comments for theclaim object; and storing comments received in the chatbot UI asassociated with the claim object.
 5. The method of claim 3, wherein thestored comments are presented in the second portion of the graphicalrepresentation of the claim object.
 6. The method of claim 2, whereinupdating the representation of the claim object includes: removingpresentation of transaction details of the particular transaction fromthe first portion of the graphical representation of the claim object;and adding presentation of the details of the another transaction to thefirst portion of the graphical representation of the claim object. 7.The method of claim 2, wherein the graphical representation of the claimobject is configured as a carousel user interface object.
 8. The methodof claim 2, wherein the second portion of the graphical representationof the claim object displays summary details of the claim object thatremain the same after receiving the swipe user interaction.
 9. Themethod of claim 8, wherein the first transaction details portionincludes a plurality of graphical indicators equal to a number oftransactions in the claim object.
 10. The method of claim 9, wherein,prior to receiving the swipe user interaction, a first of the pluralityof graphical indicators is filled in and wherein after receiving theswipe user interaction, the first of the plurality pluralities ofgraphical indicators is not filled in and a second of the plurality ofgraphical indicators is filled in.
 11. A non-transitorycomputer-readable medium comprising instructions, which when executed bya processing unit, configure the processing unit to perform operationscomprising: presenting a chatbot user interface (UI), to a user, on aclient device, the chatbot UI instantiated with respect to a particulartransaction of a plurality of transactions associated with respectiveactivity on a user account; receiving, via the chatbot UI, a responsefrom the user indicating that the user activity with respect to theparticular transaction was not authorized by the user; based on theresponse from the user, generating a claim object that identifies theparticular transaction as unauthorized; presenting a graphicalrepresentation of the claim object in the chatbot UI, the representationincluding transaction details of the particular transaction identifiedby the user as unauthorized; receiving an indication of a swipe userinteraction on the graphical representation of the claim object; and inresponse to the indication, updating a first portion of the graphicalrepresentation of the claim object to present details of anothertransaction identified by the user as unauthorized while keeping asecond portion of the graphical representation of the claim object thesame.
 12. The non-transitory computer-readable medium of claim 11,wherein the instructions, when executed by the processing unit, furtherconfigure the processing unit to perform operations comprising: prior tothe generating, presenting a query in the chatbot UI to user to identifythe another transaction as unauthorized; and based on receiving anaffirmative response from the user via the chatbot UI, adding theanother transaction as part of the claim object.
 13. The non-transitorycomputer-readable medium of claim 12, wherein receiving the affirmativeresponse from the user via the chatbot UI includes: presenting aplurality of selectable buttons in the chatbot UI, a first selectablebutton indicating the another transaction is recognized and a secondselectable button indicating the another transaction is not recognized;and receiving an indication the second selectable button has beenactivated.
 14. The non-transitory computer-readable medium of claim 12,wherein the instructions, when executed by the processing unit, furtherconfigure the processing unit to perform operations comprising: prior tothe generating, presenting a query in the chatbot UI to user requestingcomments for the claim object; and storing comments received in thechatbot UI as associated with the claim object.
 15. The non-transitorycomputer-readable medium of claim 13, wherein the stored comments arepresented in the second portion of the graphical representation of theclaim object.
 16. The non-transitory computer-readable medium of claim12, wherein updating the representation of the claim object includes:removing presentation of transaction details of the particulartransaction from the first portion of the graphical representation ofthe claim object; and adding presentation of the details of the anothertransaction to the first portion of the graphical representation of theclaim object.
 17. The non-transitory computer-readable medium of claim12, wherein the graphical representation of the claim object isconfigured as a carousel user interface object.
 18. The non-transitorycomputer-readable medium of claim 12, wherein the second portion of thegraphical representation of the claim object displays summary details ofthe claim object that remain the same after receiving the swipe userinteraction.
 19. The non-transitory computer-readable medium of claim18, wherein the first transaction details portion includes a pluralityof graphical indicators equal to a number of transactions in the claimobject.
 20. A system comprising: at least one processor; and a storagedevice comprising instructions, which when executed by a processingunit, configure the processing unit to perform operations comprising:presenting a chatbot user interface (UI), to a user, on a client device,the chatbot UI instantiated with respect to a particular transaction ofa plurality of transactions associated with respective activity on auser account; receiving, via the chatbot UI, a response from the userindicating that the user activity with respect to the particulartransaction was not authorized by the user; based on the response fromthe user, generating a claim object that identifies the particulartransaction as unauthorized; presenting a graphical representation ofthe claim object in the chatbot UI, the representation includingtransaction details of the particular transaction identified by the useras unauthorized; receiving an indication of a swipe user interaction onthe graphical representation of the claim object; and in response to theindication, updating a first portion of the graphical representation ofthe claim object to present details of another transaction identified bythe user as unauthorized while keeping a second portion of the graphicalrepresentation of the claim object the same.